[レポート] RET207: 次世代のEコマースアーキテクチャ #reinvent

はじめに

本記事はAWS re:Invent 2018のセッション「RET207 - Next-Generation e-Commerce Architectures」のレポートです。

In this session, we review the most modern e-commerce architectures, patterns, and technologies that are being used by digital innovators. We examine micro-services as well as event-driven and event-sourced architectures. We provide examples of how these patterns are implemented on AWS, and we review the benefits of each one. Learn how to select a pattern for your workload and which combination of AWS services can be used to build them. We use real-world customer examples so you can see the practical applications of these patterns.

スピーカーは以下のお二人。

• Bastien Leblanc - Solutions Architect , AWS Solutions Architecture, Amazon
• Charles Wilkinson - Head of Architecture, River Island

レポート

Eコマースはとても大変
　顧客は常に増加し続けている
　Amazonのトラフィック。毎年右肩上がりに増えている
　　Black FridayとかPrime Dayとか...
　アクセスはとてもピーキー。バーストする

重要なチャレンジ
　スケール可能
　規模に合わせたインフラのアップグレード
　アクセス予測
　特徴の分析
　ピークアクセスをハンドリング出来ていますか？

レガシーなEコマースシステム
　新しくて大きなサーバの購入
　ゴミトラフィックの削除
　課題がたくさんある

リテールシステムのモダナイズ
　クラシックなりテールシステム
　　WebSphere Commerce、Oracle ATG Web Commerce、SAP Hybris
　n-Tier アーキテクチャ
　　ロードバランサ、フロントエンドサーバ、アプリケーションサーバ、データベース
　　データベースが分散出来ず可用性を担保出来ない、リスキー
　データベースのモダン化
　　高可用性、信頼性、スケーラブルの確保
　　可能ならオープンソースDBに
　　マネージドなデータベースを利用
　　MultiAZで構成
　　リードレプリカの利用
　アプリケーションのモダン化
　　パイプラインでデプロイ
　　オートスケーリンググループでResiliency: max=1に（オートヒーリング）
　　適切なオートスケールの設定
　　　CPU、オーダー、セッション、ユーザー
　SAP Hybris on AWSの例
　　全てMulti-AZのAuto Scalingで構成
　　アプリケーションのデプロイはTerraformとPackerを利用
　　レイヤー間はELBで分散
　　可用性の高いAuroraを採用、データ共有はEFS
　　レイヤーで分けることで機能拡張も負荷分散も容易
　　Hosting SAP Hybris Commerce on AWS with Piksel Retail
　River Island bespoke .NET stack
　　Webサーバ、アプリケーションサーバ、Solrを全てMulti-AZのAuto Scalingで構成

次世代Eコマース
　ビジネスの中心を変更することに対するプレッシャー
　6ヶ月も変更していなかったWebサイト
　停止期間中のビジネス損失
　スケーラブルとアジリティの確保
　最小限の変更・停止が必要
　アクセス予測ができること
　コストエフェクティブであること
　分離可能なマイクロサービスであること
　　大規模な一つのシステムはコストも高い
　　小さく分離することで開発コストも維持コストも削減出来る
　運用が最適化されること

どうやって始めるか？
　ミッション・ステートメント：ビジネスのアジリティを高めること
　ケーパビリティ
　　検索、カタログ、料金設定、支払い、商品管理、カートとチェックアウト、顧客情報管理...
　ネクストステップ
　　既存のモノリシックなシステムを分解する
　　独立したサービスを構築する
　　サービスをAPI化して公開
　　ビジネスイベントで公開
　　全体よりも各ケイパビリティを意識してデザイン
　マイクロサービス化するための検討
　　イベントのシステム間連携をどのように実現するか
　　　SQS？MQ？Kinesis？
　　ストレージの選定。S3？データベース？
　　アプリケーションを動かすコンピュートリソースの選定
　　　フレキシブルで大きなアクセスにも対応可能なこと
　　　コストエフェクティブであること
　　　効率的にアプリケーションがデプロイ出来ること
　　　コンテナ(ECS、EKS)、サーバレス(Lambda、Step Functions)
　　Eコマースは多様なイベントが発生する
　　　適切な処理をするための選定をしましょう
　River Islandでのサーバレス
　　イベントストリームとしてKinesisを採用
　　Lambdaで各種処理を実行
　　Eコマースの各種イベントがKinesisを経由してLambdaで処理される
　　OracleからのプッシュイベントをAPI Gatewayを経由してKinesisへ
　　イベントによってはLambda経由でコンテナで処理
　　PII(Personally identifiable information)データをLambdaで処理してクリーン化
　イベント連携
　　ゆるく連携
　　API連携かメッセージング連携のパターンがある
　　SQSとKinesisの使い分け
　　　SQS
　　　　チープに使える
　　　　アカウントを横断してアクセス可能
　　　　オートスケーリングに対応可能
　　　Kinesis
　　　　マルチコンシューマーにデフォルトで対応
　　　　大規模アクセスにも対応
　　　　Lambdaとの連携が容易
　S3 or データベース
　　オープンで拡張性があること
　　クラウドネイティブ
　　マルチリージョンでアクセス可能
　　スケールできること
　　3つの選択肢。Aurora、DynamoDB、S3
　　　Aurora
　　　　他のDBからの移行が簡単
　　　　AWSの各種サービスとの連携が容易
　　　　マルチリージョン対応可能
　　　　強いスキーマを持つ
　　DynamoDB
　　　マルチリージョン、低レイテンシ、サーバレス
　　　DynamoDB streamsが使える
　　S3
　　　データレイクとして利用
　　　非構造データを格納　
　　River Islandの選択
　　　Aurora for MySQLを利用
　　　KVSとしてDynamoDBを採用
　　　S3をデータレイクとして活用
　　　幾つかのチームではPostgreSQLを使ってる

Eコマースのイベントオブジェクト
　Event Sourcingの引用
　全てのイベントをキャプチャする
　　Kinesis or SQS、S3にストア
　全てのイベントを格納し検索可能に、再現も可能に
　　全てのイベントをS3に→Redshift，Athena，EMR等で検索可能

サマリ
　スタティックなコンテンツはS3に
　API Gateway経由でCompute(コンテナ、サーバレス)を使う
　Messagingを活用（SQS/Kinesis)
　ストレージは多様な選択肢から選択
　オンプレミスステムをマイグレーションまたはリフト&シフトでAWSへ
　Start small and Think Big 　　

さいごに

AWSの活用としてはベーシックではありますが有効的なアーキテクチャの紹介でした。